Nice result and nice color too!

Please move the files to symbols/generating_patterns directory and add basic documentation about how to generate it to the file named like scrub.md.

Pattern looks good, the symbol color is too grayish i think - it does not have to be as strong as with the old pattern but it should be at least the same chroma as the base color.

The color was derived by starting with scrub color and then dialing down the lightness and saturation. I did go pretty far with the saturation, as it seems that natural=wood is rather grayish to me also. I'll make the documentation changes when I get back to a computer, and also experiment with some saturation changes.

You should do color adjustments in a perceptually uniform color space

Good point to start:

http://davidjohnstone.net/pages/lch-lab-colour-gradient-picker#b6e3b5,a1c8a1,9dc99d

What do you think of #7ebd7f?

Compare to the original example color #94b995

Yes, better - maybe even somewhat strong so it could be lightened a bit.

The pattern by the way should probably go into the landcover-area-symbols layer so it drawn above other landcovers like for wood/forest.

Symbol definition has been moved to landcover_area_symbols, scrub.md has been added, changed icon color to #8ece8f (about 5% lighter):

By the way i added the scrub symbol used here as scrub2 to jsdotpattern and converted it to a filled polygon instead of strokes making it more in line with other SVGs used here - you might want to change this accordingly.

Thanks, that will make it a lot easier to reproduce the images. I was having problems getting the original scrub icon on jsdotpattern pixel aligned, which is why I didn't use it here.

It might be a good idea to requiere Mapnik3 #2401 and make this PR directly with a SVG pattern instead of a PNG pattern…

We have a ticket about it (#2045) and it's related to #2401 and #2198.

If there are no objections, I would try to merge this PR in the current form. SVG patterns have to wait until we decide what to do with Mapnik 2.

👍

To be in line with the other patterns the SVG should be updated to use fill based rather than stroke based geometries. I was going to evaluate the pattern color intensity in comparison to other map elements but did not yet have time to do so.

I leave it to you then (I mean code update and merging).

The only important thing for me is to not wait forever with a useful change, so could you tell how much time do you think you need in reality? I just would like to take over if this safe "deadline" is crossed and nobody knows what is the current status.

Just relax - a few days more will not hurt anyone.

Besides - it would be good if @meased could update the SVG as noted.

And modify scrub.md reflecting that the symbol is now in jsdotpattern please.

Sure thing. I should be able to get that done tonight or tomorrow.

@imagico It's more about knowing that there's something stalled than doing anything fast.

There's no absolute measure of things getting stalled, but while time-based checkpoints are only relative (some things may need hours, while others weeks and months), they are super useful to detect there are any kind of problems that may need attention.

Documentation and SVG file updated. I believe everything is in order.

Looks good, nice work with the pattern and color, very well balanced.

Thanks.

Thanks a lot!

A bit off topic - interesting combination of scrub and brownfield colors:

http://www.openstreetmap.org/way/24050682

A bit off topic - interesting combination of scrub and brownfield colors:

http://www.openstreetmap.org/way/24050682

That is largely a consequence of this remark by @imagico :

The pattern by the way should probably go into the landcover-area-symbols layer so it drawn above other landcovers like for wood/forest.

While for the particular situation you pointed out (scrub & brownfield = a landcover & "kind of" administrative boundary), the implemented layering may make some sense (after all, there may be a patch of scrub on a brownfield), I am less convinced this behaviour is desired in the particular situation @imagico pointed out: something is either a forest/woodland, or its scrub, not both IMO. Unfortunately, with this current behaviour, people are likely to map both in the same place, which I don't think is a good idea and will lead to ambiguous tagging and symbolization issues: what to do with the overlapping areas?

Not all data consumers will have the ability or wish to deal with to much of this type of overlapping related features / landcovers.